React's useEvent: A Deep Dive into the Future of Stable Event Handlers

Nuolat besikeičiančiame React pasaulyje pagrindinė komanda nuolat siekia patobulinti kūrėjų patirtį ir išspręsti dažnas problemas. Vienas iš nuolatinių iššūkių kūrėjams, nuo pradedančiųjų iki patyrusių ekspertų, yra įvykių apdorojimo valdymas, referencinis vientisumas ir liūdnai pagarsėję priklausomybių masyvai tokiuose kabliukuose kaip useEffect ir useCallback. Daugelį metų kūrėjai laviravo tarp našumo optimizavimo ir klaidų, tokių kaip pasenę uždarymai, vengimo.

Pristatome useEvent, siūlomą kabliuką, kuris sukėlė didelį susidomėjimą React bendruomenėje. Nors jis vis dar yra eksperimentinis ir dar nėra stabilios React versijos dalis, jo koncepcija leidžia žvilgtelėti į ateitį su intuityvesniu ir patikimesniu įvykių apdorojimu. Šiame išsamiame vadove bus nagrinėjamos problemos, kurias useEvent siekia išspręsti, kaip jis veikia, jo praktinis pritaikymas ir potenciali jo vieta ateityje React kūrime.

The Core Problem: Referential Integrity and The Dependency Dance

Norėdami tikrai įvertinti, kodėl useEvent yra toks svarbus, pirmiausia turime suprasti problemą, kurią jis skirtas išspręsti. Problema kyla iš to, kaip JavaScript tvarko funkcijas ir kaip veikia React atvaizdavimo mechanizmas.

What is Referential Integrity?

JavaScript kalboje funkcijos yra objektai. Kai apibrėžiate funkciją React komponente, kiekvieną kartą atvaizduojant sukuriamas naujas funkcijos objektas. Apsvarstykite šį paprastą pavyzdį:

            
function MyComponent({ onLog }) {
  const handleClick = () => {
    console.log('Button clicked!');
  };

  // Every time MyComponent re-renders, a brand new `handleClick` function is created.
  return <button onClick={handleClick}>Click Me</button>;
}

            

              
                Copy
              
            
          

Paprastam mygtukui tai paprastai nekenkia. Tačiau React kalboje šis elgesys turi didelį poveikį, ypač kai susiduriama su optimizavimu ir efektais. React našumo optimizavimas, pvz., React.memo, ir pagrindiniai kabliukai, pvz., useEffect, remiasi negiliu priklausomybių palyginimu, kad nuspręstų, ar paleisti iš naujo, ar atvaizduoti. Kadangi kiekvieną kartą atvaizduojant sukuriamas naujas funkcijos objektas, jo nuoroda (arba atminties adresas) visada skiriasi. React požiūriu, oldHandleClick !== newHandleClick, net jei jų kodas yra identiškas.

The `useCallback` Solution and Its Complications

React komanda pateikė įrankį šiam valdymui: useCallback kabliuką. Jis memoizuoja funkciją, o tai reiškia, kad grąžina tą pačią funkcijos nuorodą pakartotinai atvaizduojant, jei jos priklausomybės nepasikeitė.

            
import React, { useState, useCallback } from 'react';

function MyComponent() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    // This function's identity is now stable across re-renders
    console.log(`Current count is: ${count}`); 
  }, [count]); // ...but now it has a dependency

  useEffect(() => {
    // Some effect that depends on the click handler
    setupListener(handleClick);
    return () => removeListener(handleClick);
  }, [handleClick]); // This effect re-runs whenever handleClick changes

  return <button onClick={() => setCount(c => c + 1)}>Increment</button>;
}

            

              
                Copy
              
            
          

Čia handleClick bus nauja funkcija tik tuo atveju, jei pasikeis count. Tai išsprendžia pradinę problemą, bet įveda naują: priklausomybių masyvo šokį. Dabar mūsų useEffect kabliukas, kuris naudoja handleClick, turi nurodyti handleClick kaip priklausomybę. Kadangi handleClick priklauso nuo count, efektas bus paleistas iš naujo kiekvieną kartą, kai skaičius pasikeis. Tai gali būti tai, ko norite, bet dažnai taip nėra. Galbūt norėsite nustatyti klausytoją tik vieną kartą, bet kad jis visada iškviestų *naujausią* spustelėjimo apdoroklio versiją.

The Peril of Stale Closures

Ką daryti, jei bandome apgauti? Dažnas, bet pavojingas modelis yra praleisti priklausomybę iš useCallback masyvo, kad funkcija būtų stabili.

            
// ANTI-PATTERN: DO NOT DO THIS
const handleClick = useCallback(() => {
  console.log(`Current count is: ${count}`); 
}, []); // Omitted `count` from dependencies

            

              
                Copy
              
            
          

Tai yra pagrindinė dilema: jūs arba turite nuolat besikeičiančią funkcijos nuorodą, kuri sukelia nereikalingą pakartotinį atvaizdavimą ir efekto pakartotinį paleidimą, arba rizikuojate įvesti subtilias ir sunkiai derinamas pasenusio uždarojo kodo klaidas.

Introducing `useEvent`: The Best of Both Worlds

Siūlomas useEvent kabliukas skirtas nutraukti šį kompromisą. Jo pagrindinis pažadas yra paprastas, bet revoliucinis:

Pateikite funkciją, kuri turi nuolat stabilią tapatybę, bet kurios įgyvendinimas visada naudoja naujausią, atnaujintą būseną ir rekvizitus.

Pažvelkime į jo siūlomą sintaksę:

            
import { useEvent } from 'react'; // Hypothetical import

function MyComponent() {
  const [count, setCount] = useState(0);

  const handleClick = useEvent(() => {
    // No dependency array needed!
    // This code will always see the latest `count` value.
    console.log(`Current count is: ${count}`);
  });

  useEffect(() => {
    // setupListener is called only once on mount.
    // handleClick has a stable identity and is safe to omit from the dependency array.
    setupListener(handleClick);
    return () => removeListener(handleClick);
  }, []); // No need to include handleClick here!

  return <button onClick={() => setCount(c => c + 1)}>Increment</button>;
}

            

              
                Copy
              
            
          

Atkreipkite dėmesį į du pagrindinius pakeitimus:

1. useEvent priima funkciją, bet neturi jokio priklausomybių masyvo.
2. handleClick funkcija, grąžinama useEvent, yra tokia stabili, kad React dokumentai oficialiai leistų ją praleisti iš useEffect priklausomybių masyvo (lint taisyklė būtų išmokyta ją ignoruoti).

Tai elegantiškai išsprendžia abi problemas. Funkcijos tapatybė yra stabili, todėl useEffect nepaleidžiamas iš naujo be reikalo. Tuo pačiu metu, kadangi jos vidinė logika visada atnaujinama, ji niekada nepatiria pasenusių uždarųjų kodų. Jūs gaunate stabilaus nuorodos našumo pranašumą ir visada turite naujausius duomenis.

`useEvent` in Action: Practical Use Cases

useEvent pasekmės yra didžiulės. Panagrinėkime keletą dažnų scenarijų, kai tai labai supaprastintų kodą ir pagerintų patikimumą.

1. Simplifying `useEffect` and Event Listeners

Tai yra kanoninis pavyzdys. Visuotinio įvykių klausytojų (pvz., lango dydžio keitimo, sparčiųjų klavišų arba WebSocket pranešimų) nustatymas yra dažna užduotis, kuri paprastai turėtų įvykti tik vieną kartą.

Before `useEvent`:

            
function ChatRoom({ roomId }) {
  const [messages, setMessages] = useState([]);

  const onMessage = useCallback((newMessage) => {
    // We need `messages` to add the new message
    setMessages([...messages, newMessage]);
  }, [messages]); // Dependency on `messages` makes `onMessage` unstable

  useEffect(() => {
    const socket = createSocket(roomId);
    socket.on('message', onMessage);
    return () => socket.off('message', onMessage);
  }, [roomId, onMessage]); // Effect re-subscribes every time `messages` changes
}

            

              
                Copy
              
            
          

Šiame kode kiekvieną kartą, kai atkeliauja naujas pranešimas ir atnaujinama messages būsena, sukuriama nauja onMessage funkcija. Tai sukelia useEffect nugriauti seną lizdo prenumeratą ir sukurti naują. Tai neefektyvu ir netgi gali sukelti klaidų, pvz., prarastus pranešimus.

After `useEvent`:

            
function ChatRoom({ roomId }) {
  const [messages, setMessages] = useState([]);

  const onMessage = useEvent((newMessage) => {
    // `useEvent` ensures this function always has the latest `messages` state
    setMessages([...messages, newMessage]);
  });

  useEffect(() => {
    const socket = createSocket(roomId);
    socket.on('message', onMessage);
    return () => socket.off('message', onMessage);
  }, [roomId]); // `onMessage` is stable, so we only re-subscribe if `roomId` changes
}

            

              
                Copy
              
            
          

Dabar kodas yra paprastesnis, intuityvesnis ir teisingesnis. Lizdo ryšys valdomas tik pagal roomId, kaip ir turėtų būti, o pranešimų įvykių apdoroklis skaidriai tvarko naujausią būseną.

2. Optimizing Custom Hooks

Individualūs kabliukai dažnai priima atgalinio iškvietimo funkcijas kaip argumentus. Individualaus kabliuko kūrėjas nekontroliuoja, ar vartotojas perduoda stabilią funkciją, todėl gali atsirasti našumo spąstų.

Before `useEvent`:

Individualus kabliukas, skirtas apklausti API:

            
function usePolling(url, onData) {
  useEffect(() => {
    const intervalId = setInterval(async () => {
      const data = await fetch(url).then(res => res.json());
      onData(data);
    }, 5000);

    return () => clearInterval(intervalId);
  }, [url, onData]); // Unstable `onData` will restart the interval
}

// Component using the hook
function StockTicker() {
  const [price, setPrice] = useState(0);

  // This function is re-created on every render, causing the polling to restart
  const handleNewPrice = (data) => {
    setPrice(data.price);
  };

  usePolling('/api/stock', handleNewPrice);

  return <div>Price: {price}</div>
}

            

              
                Copy
              
            
          

Norėdami tai ištaisyti, usePolling vartotojas turėtų atsiminti, kad handleNewPrice reikia suvynioti į useCallback. Dėl to kabliuko API tampa mažiau ergonomiškas.

After `useEvent`:

Individualus kabliukas gali būti padarytas viduje patikimas su useEvent.

            
function usePolling(url, onData) {
  // Wrap the user's callback in `useEvent` inside the hook
  const stableOnData = useEvent(onData);

  useEffect(() => {
    const intervalId = setInterval(async () => {
      const data = await fetch(url).then(res => res.json());
      stableOnData(data); // Call the stable wrapper
    }, 5000);

    return () => clearInterval(intervalId);
  }, [url]); // Now the effect only depends on `url`
}

// Component using the hook can be much simpler
function StockTicker() {
  const [price, setPrice] = useState(0);

  // No need for useCallback here!
  usePolling('/api/stock', (data) => {
    setPrice(data.price);
  });

  return <div>Price: {price}</div>
}

            

              
                Copy
              
            
          

Atsakomybė perkeliama kabliuko autoriui, todėl visi kabliuko vartotojai gauna švaresnę ir saugesnę API.

3. Stable Callbacks for Memoized Components

Perduodami atgalinio iškvietimo funkcijas kaip rekvizitus komponentams, suvyniotiems į React.memo, turite naudoti useCallback, kad išvengtumėte nereikalingų pakartotinių atvaizdavimų. useEvent suteikia tiesioginį būdą deklaruoti ketinimą.

            
const MemoizedButton = React.memo(({ onClick, children }) => {
  console.log('Rendering button:', children);
  return <button onClick={onClick}>{children}</button>;
});

function Dashboard() {
  const [user, setUser] = useState('Alice');

  // With `useEvent`, this function is declared as a stable event handler
  const handleSave = useEvent(() => {
    saveUserDetails(user);
  });

  return (
    <div>
      <input value={user} onChange={e => setUser(e.target.value)} />
      {/* `handleSave` has a stable identity, so MemoizedButton won't re-render when `user` changes */}
      <MemoizedButton onClick={handleSave}>Save</MemoizedButton>
    </div>
  );
}

            

              
                Copy
              
            
          

Šiame pavyzdyje, kai rašote į įvesties laukelį, user būsena pasikeičia ir Dashboard komponentas atvaizduojamas iš naujo. Be stabilios handleSave funkcijos, MemoizedButton būtų atvaizduojamas iš naujo kiekvieną kartą paspaudus klavišą. Naudodami useEvent, signalizuojame, kad handleSave yra įvykių apdoroklis, kurio tapatybė neturėtų būti susieta su komponento atvaizdavimo ciklu. Jis išlieka stabilus, neleidžia mygtukui atvaizduoti iš naujo, bet spustelėjus visada iškvies saveUserDetails su naujausia user verte.

Under the Hood: How Does `useEvent` Work?

Nors galutinis įgyvendinimas būtų labai optimizuotas React viduje, galime suprasti pagrindinę koncepciją sukurdami supaprastintą polifilą. Magija slypi derinant stabilią funkcijos nuorodą su kintamu ref, kuriame yra naujausias įgyvendinimas.

Štai konceptualus įgyvendinimas:

            
import { useRef, useLayoutEffect, useCallback } from 'react';

export function useEvent(handler) {
  // Create a ref to hold the latest version of the handler function.
  const handlerRef = useRef(null);

  // `useLayoutEffect` runs synchronously after DOM mutations but before the browser paints.
  // This ensures the ref is updated before any event can be triggered by the user.
  useLayoutEffect(() => {
    handlerRef.current = handler;
  });

  // Return a stable, memoized function that never changes.
  // This is the function that will be passed as a prop or used in an effect.
  return useCallback((...args) => {
    // When called, it invokes the *current* handler from the ref.
    const fn = handlerRef.current;
    return fn(...args);
  }, []);
}

            

              
                Copy
              
            
          

Suskaidykime tai:

1. `useRef`: Sukuriame handlerRef. Ref yra kintamas objektas, kuris išlieka tarp atvaizdavimų. Jo .current savybė gali būti keičiama nesukeliant pakartotinio atvaizdavimo.
2. `useLayoutEffect`: Kiekvieną kartą atvaizduojant, šis efektas paleidžiamas ir atnaujina handlerRef.current, kad būtų nauja handler funkcija, kurią ką tik gavome. Mes naudojame useLayoutEffect vietoj useEffect, kad užtikrintume, jog šis atnaujinimas įvyksta sinchroniškai, kol naršyklė turi galimybę atvaizduoti. Tai apsaugo nuo mažo lango, kuriame įvykis galėtų paleisti ir iškviesti pasenusią apdoroklio versiją iš ankstesnio atvaizdavimo.
3. `useCallback` with `[]`: Tai yra stabilumo raktas. Mes sukuriame apvyniojimo funkciją ir ją memoizuojame su tuščiu priklausomybių masyvu. Tai reiškia, kad React *visada* grąžins tą patį funkcijos objektą šiam apvyniojimui per visus atvaizdavimus. Tai yra stabili funkcija, kurią gaus mūsų kabliuko vartotojai.
4. The Stable Wrapper: Šios stabilios funkcijos vienintelis darbas yra nuskaityti naujausią apdoroklį iš handlerRef.current ir jį vykdyti, perduodant visus argumentus.

Šis protingas derinys suteikia mums funkciją, kuri yra stabili iš išorės (apvyniojimas), bet visada dinamiška viduje (skaitant iš ref), puikiai išsprendžiant mūsų dilemą.

The Status and Future of `useEvent`

Nuo 2023 m. pabaigos ir 2024 m. pradžios useEvent nebuvo išleistas stabilioje React versijoje. Jis buvo pristatytas oficialiame RFC (Request for Comments) ir kurį laiką buvo prieinamas React eksperimentiniame leidimo kanale. Tačiau pasiūlymas nuo to laiko buvo atsiimtas iš RFC saugyklos, o diskusijos aprimo.

Kodėl pauzė? Yra keletas galimybių:

• Edge Cases and API Design: Pristatyti naują primityvų kabliuką į React yra didžiulis sprendimas. Komanda galėjo aptikti sudėtingų kraštutinių atvejų arba gauti bendruomenės atsiliepimų, kurie paskatino iš naujo pagalvoti apie API arba jo pagrindinį elgesį.
• The Rise of the React Compiler: Pagrindinis nuolatinis React komandos projektas yra „React Compiler“ (anksčiau vadintas „Forget“). Šis kompiliatorius siekia automatiškai memoizuoti komponentus ir kabliukus, veiksmingai pašalindamas kūrėjų poreikį rankiniu būdu naudoti useCallback, useMemo ir React.memo daugeliu atvejų. Jei kompiliatorius yra pakankamai protingas, kad suprastų, kada funkcijos tapatybę reikia išsaugoti, jis galėtų išspręsti problemą, kuriai buvo sukurtas useEvent, bet fundamentalesniu, automatizuotu lygiu.
• Alternative Solutions: Pagrindinė komanda gali ieškoti kitų, galbūt paprastesnių, API, kad išspręstų tą pačią problemų klasę nepristatant visiškai naujos kabliuko koncepcijos.

Kol laukiame oficialios krypties, *koncepcija* už useEvent išlieka nepaprastai vertinga. Ji suteikia aiškų protinį modelį, skirtą atskirti įvykio tapatybę nuo jo įgyvendinimo. Net ir be oficialaus kabliuko, kūrėjai gali naudoti aukščiau esantį polifilo modelį (dažnai randamą bendruomenės bibliotekose, pvz., use-event-listener), kad pasiektų panašių rezultatų, nors ir be oficialaus palaiminimo ir linter palaikymo.

Conclusion: A New Way of Thinking About Events

useEvent pasiūlymas pažymėjo reikšmingą momentą React kabliukų evoliucijoje. Tai buvo pirmasis oficialus React komandos pripažinimas dėl savaiminės trinties ir pažinimo perkrovos, kurią sukelia funkcijos tapatybės, useCallback ir useEffect priklausomybių masyvų sąveika.

Nesvarbu, ar useEvent pats taps React stabilios API dalimi, ar jo dvasia bus įtraukta į būsimą React Compiler, problema, kurią jis išryškina, yra reali ir svarbi. Ji skatina mus aiškiau galvoti apie mūsų funkcijų pobūdį:

• Ar tai funkcija, kuri reprezentuoja įvykio apdoroklį, kurio tapatybė turėtų būti stabili?
• Ar tai funkcija, perduota efektui, kuris turėtų sukelti efekto iš naujo sinchronizavimą, kai pasikeičia funkcijos logika?

Pateikdamas įrankį – arba bent jau koncepciją – aiškiai atskirti šiuos du atvejus, React gali tapti deklaratyvesnis, mažiau linkęs į klaidas ir malonesnis dirbti. Kol laukiame galutinės jo formos, gilus įžvalgų į useEvent suteikia neįkainojamą supratimą apie sudėtingų programų kūrimo iššūkius ir nuostabią inžineriją, kuri leidžia tokią sistemą kaip React jaustis ir galinga, ir paprasta.